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1 Scope and purpose 

1.1 Scope 

This standard defines a Reduced Block Command set for logical block devices. The Reduced Block 
Commands along with the required SPC-2 commands and their restrictions described in this standard, 
fully specify the complete command set for RBC logical block devices. 

1.2 Purpose 

The purpose of this document is to provide a command set of reduced requirements and options from 
SCSI Block Commands (ANSI NCITS 306-1998) for block devices. The reduced command set is 
intended to more closely match the functionality required for simple block logical units. The specified 
commands place no restrictions on device performance. The initial focus of this command set was 
rigid disks and removable media devices attached to Serial Bus and utilizing SBP-2 (ANSI NCITS 325- 
1998) for command and control. 

2 Normative references 

The standards named in this clause contain provisions that through reference in this text, constitute 
provisions of this American National Standard. At the time of publication, the editions indicated were 
valid. All standards are subject to revision; parties to agreements based on this American National 
Standard are encouraged to investigate the possibility of applying the most recent editions of the 
standards indicated below. 

Copies of the following documents may be obtained from ANSI: 

Approved ANSI standards; 

Approved and draft regional and international standards (ISO, IEC, CEN/CENELEC and 
ITUT); and 

Approved foreign standards (including BIS, JIS and DIN). 

For further information, contact the ANSI Customer Service Department by telephone at (212) 642- 
4900, by FAX at (212) 302-1286 or via the World Wide Web at http://www.ansi.org. 

Additional contact information for document availability is provided below as needed. 

2.1 Approved references 

ANSI NCITS 306-1998, Information Technology - SCSI-3 Block Commands (SBC) 

ANSI NCITS 325-1998, Information Technology - Serial Bus Protocol 2 (SBP-2) 

ANSI/IEEE 1394-1995, High Performance Serial Bus 

ISO/IEC 13213:1994, Control and Status Register (CSR) Architecture for Microcomputer 
Buses 

NCITS 306-1998, SCSI-3 Block Commands (SBC) 

NCITS 325-1998, Serial Bus Protocol 2 (SBP-2) 

2.1.1 References under development 

At the time of publication, the following referenced standards were still under development. 
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IEEE PI 394a, Draft Standard for a High Performance Serial Bus (Supplement-f 1 

T10 Project 1228D MultiMedia Command Set 2 (MMC-2) T10 Project 1236D, SCSI Primary 

Commands 2 (SPC-2) 2) 

2.1.2 Other references 

The following standards and specification were also consulted. 

T10 Project 1157D SCSI Architecture Model 2 (SAM-2) 

3 Definitions, Acronyms, Keywords, and Conventions 

3.1 Definitions 

The following terms are used in this standard: 

3.1.1 additional sense code: A field in the sense data (see Glossary definition in SPC-2. 

3.1.2 additional sense code qualifier: A field in the sense data (see Glossary definition in SPC-2). 

3.1.3 byte: Eight bits of data. 

3.1.4 command descriptor block: A structure of up to 16 bytes in length used to communicate a 

command from an initiator to a device. 

3.1.5 event field: Byte 0 of the sense data information field (see Table 24 for the Event Status 
information field format) when the sense code indicates EVENT STATUS NOTIFICATION (38h). 

3.1.6 logical unit: The part of the target that is an instance of a device model, e.g., mass storage, 
CD-ROM or printer. In devices that implement one or more logical units, the device type of the 
logical units may differ. 

3.1.7 sense data: Data describing an error or exceptional device condition that a device delivers to 

an initiator (see Glossary definition in SPC-2). 

3.1.8 sense key: A field in the sense data (see Glossary definition in SPC-2). 

3.1.9 status: Response information sent from a device to an initiator upon completion of each 

command. 

3.1.10 unit attention condition: A state that a logical unit maintains while it has asynchronous 

status information to report to one or more initiators. 

3.1.11 vendor-specific: Something (e.g. a bit, field, code value, etc.) that is not defined by this 

standard and may be vendor defined. 

3.2 Acronyms 

The following are abbreviations that are used in this standard: 


ASC 

Additional Sense Code 

ASCQ 

Additional Sense Code Qualifier 

CDB 

Command Descriptor Block 

RBC 

Reduced Block Commands (this standard) 


Available from Institute of Electrical and Electronics Engineers, 445 Hoes Lane, P.D. Box 1331, Piscataway, 
NJ 08855-1331. 

2) Available from NCITS, Information Technology Industry Council, 1250 Eye Street, NW, Suite 200, Washington, 
DC 20005-3922. 
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SPC-2 SCSI Primary Commands 2 

3.3 Keywords 

Several keywords are used to differentiate levels of requirements and options, as follows: 

3.3.1 expected: A keyword used to describe the behavior of the hardware or software in the design 
models assumed by this standard. Other hardware and software design models may also be 
implemented. 

3.3.2 ignored: A keyword that describes bits, bytes, quadlets, or fields whose values are not 
checked by the recipient. 

3.3.3 mandatory: A keyword that indicates items required to be implemented as defined by this 
standard. 

3.3.4 may: A keyword that indicates flexibility of choice with no implied preference. 

3.3.5 optional: A keyword that describes features which are not required to be implemented by this 
standard. However, if any optional feature defined by the standard is implemented, it shall be 
implemented as defined by the standard. 

3.3.6 reserved: A keyword used to describe objects—bits, bytes, and fields—or the code values 
assigned to these objects in cases where either the object or the code value is set aside for future 
standardization. Usage and interpretation may be specified by future extensions to this or other 
standards. A reserved object shall be zeroed or, upon development of a future standard, set to a 
value specified by such a standard. The recipient of a reserved object shall not check its value. 
The recipient of a defined object shall check its value and reject reserved code values. 

3.3.7 shall: A keyword that indicates a mandatory requirement. Designers are required to 

implement all such mandatory requirements to assure interoperability with other products 
conforming to this standard. 

3.4 Conventions 

The following conventions shall be understood by the reader in order to comprehend this standard. 

3.4.1 Non-numeric values 

Lowercase is used for words having the normal English meaning. Certain words and terms used in 
this standard have a specific meaning beyond the normal English meaning. These words and terms 
are defined either in Clause 0 or in the text where they first appear. 

Listed items in RBC do not represent any priority. Any priority is explicitly indicated. Formal lists 
e.g.,(a) red; (b) blue; (c) green) connoted by letters are in an arbitrary order. Formal lists e.g., (1) red; 
(2) blue; (3) green) connoted by numbers are in a required sequential order. 

If a conflict arises between text, tables, or figures, the order of precedence to resolve conflicts is text; 
then tables; and finally figures. Not all tables or figures are fully described in text. Tables show data 
format and values. Notes and IMPLEMENTATION Notes do not constitute any requirements for 
implementations. 

a) The names of abbreviations, commands, and acronyms are in all uppercase, e.g. TEST UNIT 
READY command. 

b) Fields containing only one bit are usually referred to as the "NAME" bit instead of the "NAME" 
field. 

c) Fields are shown in caps, e.g. LOGICAL BLOCK ADDRESS. 

3.4.2 Numeric values 

The ISO convention of numbering is used (i.e., the thousands and higher multiples are separated by a 
space and a comma is used as the decimal point as in 65 536 or 0,5). 

a) Decimal numbers are represented by Arabic numerals without subscripts or by their English 
names, e.g. 42, or twelve. 

b) Hexadecimal numbers are represented by digits from the character set 0 - 9 and A - F followed 
by the lower-case h, e.g. 2Ah. 


3 



BSR NCITS 330 


c) Binary numbers are represented by digits from the character set 0 and 1 followed by the lower¬ 
case b, e.g. 0010 1010b. 

d) The most significant bit of a binary quantity is shown on the left side and represents the highest 
algebraic value position in the quantity. 

e) For the sake of legibility, binary and hexadecimal numbers are separated into groups of four digits 
separated by spaces. 


4 RBC device model 

RBC logical units store blocks of data for later retrieval. Each block of data is stored at a unique 
location. Initiators issue WRITE commands to store the blocks of data (write operations) and READ 
commands to retrieve the blocks of data (read operations). Other commands issued by the initiator 
may also cause write and read operations to occur. A write operation causes one or more blocks of 
data to be written on the medium. A read operation causes one or more blocks of data to be read 
from the medium. A verify operation confirms that one or more blocks of data were correctly written 
and may be read without error from the medium. 

Blocks of data are stored by a process that causes localized changes or transitions within the medium. 
The changes made to the medium to store the blocks of data may be volatile (i.e. not retained through 
off/on power cycles) or non-volatile (retained through off/on power cycles). The medium may be 
divided in parts that are used for data blocks, parts that are reserved for defect management, and 
parts that are reserved for use by the target for the management of the logical unit. 

4.1 Removable medium device 

The medium in a RBC device may be removable (e.g., used in a floppy disk drive) or non-removable 
(e.g. used in a fixed disk drive). Typically, removable medium is contained within a cartridge (or 
jacket) to prevent damage to the recording surfaces. 

A removable medium has an attribute of being mounted or de-mounted on a suitable transport 
mechanism. A removable medium is mounted when the device/media combination is capable of 
performing write or read operations and the initiator is informed of this status. A removable medium is 
de-mounted at any other time (e.g., during loading, unloading, or storage). 

Initiators may determine whether a RBC removable medium device is capable of performing read or 
write operations by one of three methods: 

a) Enabling AERC in the device and examining the event information transmitted from the device. 

b) Issuing a TEST UNIT READY command and examining the returned status information. 

c) Issuing a MODE SENSE command for Mode Page 06h (see 5.8.3.) and examining the state of the 
READD or WRITED bits in byte 11. If the READD bit is set to one, then the media is not readable. 

If the WRITED bit is set to one, then the media is not writable. 

Until the RBC removable medium device and media are ready to be accessed, a READ(10) command 
shall cause the device to return status of CHECK CONDITION (02h), sense key of NOT READY (02h), 
and an ASC of LOGICAL UNIT NOT READY (04h). The ASCQ shall reflect the current state of the 
device/media. 

When the device becomes ready, a unit attention condition shall be established. The sense key field 
shall be set to UNIT ATTENTION (06h), and the ASC/ASCQ to EVENT STATUS 
NOTIFICATION/MEDIA CLASS EVENT (38h/04h). The EVENT field contained within the SENSE 
DATA INFORMATION field shall be set to NEW MEDIA READY FOR ACCESS (02h). When the unit 
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attention condition is delivered to the initiator, the status field shall be set to CHECK CONDITION 
(02h). 

4.2 Command Usage 

RBC devices are not required to support the REQUEST SENSE command or the SEND DIAGNOSTIC 
command. Devices that do not provide the Auto Sense function, Asynchronous Event Reporting, or 
the GET EVENT STATUS NOTIFICATION (See MMC-2 NCITS for definition) command shall 
implement the REQUEST SENSE command. 

All SENSE KEY, ADDITIONAL SENSE CODE, and ADDITIONAL SENSE CODE QUALIFIER names 
and values contained in this standard are defined in SPC-2. No additional or alternative meaning is 
intended by the use of such names and values in this standard. 

4.2.1 Using the INQUIRY command 

The INQUIRY command may be used by an initiator to determine the configuration of a logical unit. 
RBC devices return information that includes type and standard version. The device may also return 
the vendor identification number, model number, and other vendor specific information. It is 
recommended that devices provide the capability to return this information upon completing power-on 
initialization. A device may take more time to return certain portions of this information, especially if the 
information must be retrieved from the medium. 

4.2.2 Using the REQUEST SENSE command 

Whenever a command completes with CHECK CONDITION status and AUTOSENSE Data is not 
provided, the initiator that received the error status should issue a REQUEST SENSE command to 
acquire the sense data describing the cause of the condition. If the initiator issues a command other 
than REQUEST SENSE, the sense data is lost. 

Devices may be required to support the REQUEST SENSE command if they are unable to provide 
command progress information by any other method. 

4.2.3 FORMAT UNIT command progress determination 

The FORMAT UNIT command requires IMMEDIATE bit support because it may consume significantly 
more time to complete than normal read or write commands. If the IMMEDIATE bit is one, the device 
is required to return status as soon as the command descriptor block is validated. The device then 
completes the format operation. Initiators may determine the progress of the format operation in 
several ways. 

RBC devices may provide format progress information using one of three methods. The first two 
mechanisms return data in the Event Status Notification format described in clause 0. 

The first mechanism is progress reporting via Asynchronous Event Reporting. If the initiator and 
device support this feature, the RBC device initiates progress reporting. 

The second mechanism is progress reporting via the GET EVENT STATUS NOTIFICATION(See 
MMC-2 for command definition) command. Following the return of GOOD status, the initiator may poll 
the device for command progress by issuing a GET EVENT STATUS NOTIFICATION command. The 
returned data contains progress information as defined in clause 0. 

The third mechanism is progress reporting via the PROGRESS INDICATION field in the sense-key 
specific bytes of REQUEST SENSE command sense data. See the ANSI NCITS 301 SPC standard 
for a description of this method. 

4.3 Using the PREVENT ALLOW MEDIUM REMOVAL command 

The PREVENT ALLOW MEDIUM REMOVAL command allows an initiator to restrict the de-mounting 
of the medium. This is useful in maintaining system integrity. If the removable medium device 
implements cache memory, the command allows the initiator to ensure that all logical blocks of the 
medium contain the most recent data prior to permitting de-mounting of the removable medium. 

If the initiator issues a START STOP UNIT command to eject the cartridge, and the removable 
medium device is prevented from de-mounting by the PREVENT ALLOW MEDIUM REMOVAL 
command, the START STOP unit command is rejected by the device. 
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When set to one, the RMB bit in the standard INQUIRY command data, indicates the PREVENT 
ALLOW MEDIUM REMOVAL command is not be supported. 

4.3.1 START STOP UNIT command state restrictions 

A removable medium device shall be in either PREVENT state 00b or 10b in order to successfully 
execute a START STOP UNIT command with thePOWER CONDITIONS field set to the Sleep state 
(5). 

If a removable medium device, in either PREVENT state 01b or 11b, receives a START STOP UNIT 
command with the POWER CONDITIONS field set to the Sleep state (5), the device shall respond with 
status set to CHECK CONDITION (02h), the sense key to ILLEGAL REQUEST (05h), and the 
ASC/ASCQ to ILLEGAL POWER CONDITION REQUEST (2Ch/05h). 

A removable medium device in the SLEEP State shall eject the media without causing the media to 
spin up in accordance with the PREVENT/ALLOW MEDIUM REMOVAL command requirements. 

Refer to clause 0 for a description of the POWER CONDITIONS field values. 

4.4 Logical Blocks 

Data are addressed on the RBC device in a group referred to as a Logical Block. This is a common 
attribute of RBC devices in that they are block addressable only. 

Blocks of data are stored on the medium along with additional information that the medium controller 
uses to manage the storage and retrieval of the blocks. The format of the additional information is 
defined by other standards or is vendor specific and is hidden from the application client during normal 
read or write operations. 

The address of the first logical block is zero. The address of the last logical block is [n-1], where [n] is 
the number of logical blocks available on the medium. A READ CAPACITY command may be issued 
to determine the value of [n-1]. If a command is issued that requests access to a logical block not 
within the capacity of the medium, the command is terminated with a status of CHECK CONDITION 
(02h), a sense key of ILLEGAL REQUEST (05h), and an ASC/ASCQ of LOGICAL BLOCK ADDRESS 
OUT OF RANGE (21 h/OOh). 

The number of bytes of data contained in a logical block is known as the block length. Each logical 
block has a block length associated with it. The block length is almost always greater than one byte 
and is typically (but by no means always) a multiple of 512 bytes. In addition, a logical block does not 
necessarily bear any relation to the physical block size of the storage medium. 

The LOGICAL BLOCK SIZE field in the RBC Device Parameters MODE SENSE page (see Table 14) 
describes the block length that is used on the medium. A MODE SELECT command may be used to 
set the logical block size, if the field is changeable. 

The default NUMBER OF LOGICAL BLOCKS value in the may be obtained by requesting the Default 
MODE SENSE data for the RBC Device Parameters MODE SENSE page. The current NUMBER OF 
LOGICAL BLOCKS value may be obtained by requesting the saved MODE SENSE data for this page. 
The location of a logical block on the medium does not necessarily have a relationship to the location 
of any other logical block. However, in a typical logical unit the logical blocks are located in an 
ascending order. The time to access the logical block at address [x] and then the logical block at 
address [x+1] need not be less than time to access [x] and then [x+100]. 

4.5 Reservations 

If the bus protocol does not inherently provide the ability to reserve and release access to a device, 
then this function may be supported by the RESERVE and RELEASE commands. 

Reservation restrictions are placed on commands as a result of access qualifiers associated with the 
type of reservation. 

The details of what commands are allowed under what types of reservations are described in Table 1. 
For the reservation restrictions placed on commands for the Reserve/Release management method 
see Table 1 column [A], For the reservation restrictions placed on commands for the Persistent 
Reservations management method, see the columns under [B] in Table 1. In Table 1 the following key 
words are used: 
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allowed: Commands issued by initiators not holding the reservation or by initiators not registered 
when a registrants only persistent reservation is present should complete normally, 
conflict: Commands issued by initiators not holding the reservation or by initiators not registered 
when a registrants only persistent reservation is present shall not be performed and the device server 
shall terminate the command with a RESERVATION CONFLICT status. 

Commands from initiators holding a reservation should complete normally. The behavior of commands 
from registered initiators when a registrants only persistent reservation is present is specified in Table 
1. 

A command that does not explicitly write the medium shall be checked for reservation conflicts before 
the command enters the current task state for the first time. Once the command has entered the 
current task state, it shall not be terminated with a RESERVATION CONFLICT due to a subsequent 
reservation. 

A command that explicitly writes the medium shall be checked for reservation conflicts, before the 
device server modifies the medium or cache as a result of the command. Once the command has 
modified the medium, it shall not be terminated with a RESERVATION CONFLICT due to a 
subsequent reservation. For each command, this standard, SPC-2, or a related command standard 
defines the conditions that result in RESERVATION CONFLICT. Depending on the particular 
command standard the conditions are defined in that standard’s device model clause or in the clauses 
that define the specific commands.. 


Table 1 - RBC direct access commands that are allowed in the presence of 
various reservations 


Command 

Addressed 
LU is 

reserved by 
another 
Initiator 
(A) 

Addressed LU has this type of persistent reservation 
held by another Initiator 

(B) 

From any Initiator 

From 
registered 
Initiator 
(RO all 
types) 

From Initiator not 
registered 

Write 

Excl 

Excl 

Access 

Write Excl 
-RO 

Excl 
Access 
- RO 

FORMAT UNIT 

Conflict 

Conflict 

Conflict 

Allowed 

Conflict 

Conflict 

READ (10) 

Conflict 

Allowed 

Conflict 

Allowed 

Allowed 

Conflict 

READ CAPACITY 

Allowed 

Allowed 

Allowed 

Allowed 

Allowed 

Allowed 

START STOP UNIT 

Start = 0 and Power Condition = 

0 

Allowed 

Allowed 

Allowed 

Allowed 

Allowed 

Allowed 

START STOP UNIT 

Start = 1 or Power Condition 
<>0 

Conflict 

Conflict 

Conflict 

Allowed 

Conflict 

Conflict 

VERIFY (10) 

Conflict 

Allowed 

Conflict 

Allowed 

Allowed 

Conflict 

WRITE (10) 

Conflict 

Conflict 

Conflict 

Allowed 

Conflict 

Conflict 


5 Reduced Block Commands 

The Reduced Block Command set (RBC) for block device logical units is shown in Table 2. The SCSI 
Primary Commands (SPC-2) required for RBC device implementations are also shown in Table 2. 
Support is indicated for fixed or removable drives. 
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Table 2 - Reduced Block Command set 


Command name 

OpCode 

Command Support 

Reference 

Fixed 

Removable 

FORMAT UNIT 

04h 

0 

0 

RBC 

INQUIRY 

12h 

M 

M 

SPC-2 1 

MODE SELECT(6) 

15h 

M 

M 

SPC-2 1 

MODE SENSE(6) 

1 Ah 

M 

M 

SPC-2 1 

PERSISTENT RESERVE IN 

5Eh 

0 

0 

SPC-2 1 

PERSISTENT RESERVE OUT 

5Fh 

0 

0 

SPC-2 1 

PREVENT/ALLOW MEDIUM REMOVAL 

1 Eh 

N/A 

M 

SPC-2 1 

READ (10) 

28h 

M 

M 

RBC 

READ CAPACITY 

25h 

M 

M 

RBC 

RELEASED) 

17h 

0 

0 

SPC-2 1 

REQUEST SENSE 

03h 

0 

0 

SPC-2 1 

RESERVED) 

16h 

0 

0 

SPC-2 1 

START STOP UNIT 

IBh 

M 

M 

RBC 

SYNCHRONIZE CACHE 

35h 

0 

0 

RBC 

TEST UNIT READY 

OOh 

M 

M 

SPC-2 1 

VERIFY (10) 

2Fh 

M 

M 

RBC 

WRITE (10) 

2Ah 

M 

M 

RBC 

WRITE BUFFER 

3Bh 

M 

0 

SPC-2 1 


1 - See clause 6, SPC-2 Implementation Requirements for RBC Devices. 

- Command Support key: M = support is mandatory; N/A = not applicable; O = support is 
optional. 


The control byte (the last byte of the CDB) shall be set to zero. 

5.1 FORMAT UNIT command 

This command (see Table 3) formats the media into addressable logical blocks. This command is 
optional for both fixed and removable medium devices. An Initiator shall examine the state of the 
FORMATD bit in the MODE SENSE RBC Device Parameters page (Table 14) to determine whether 
the device supports this command. 
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Table 3 - FORMAT UNIT command 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 

OPERATION CODE (04h) 

1 

Reserved 

3 

Reserved 

4 

Reserved 

5 

CONTROL = 00 h 


An IMMEDIATE (IMMED) bit value of zero indicates that status shall be returned after the format 
operation has completed. An IMMED bit value of one indicates that this device shall return status as 
soon as the command descriptor block has been validated. 

The PROGRESS bit indicates whether the initiator is requesting periodic format progress updates. If 
this bit is set to zero, no progress report shall be generated. If the PROGRESS bit is set to one then 
the device shall generate format progress based upon the values of the PERCENT/TIME and the 
INCREMENT bit. Refer to sub-clause 4.2.3 for a description of the progress reporting mechanisms for 
the format operation. 

The PERCENT/TIME bit and INCREMENT bit determine the method used to report format progress, 
whether in a percentage of completion, or in total elapsed time. 

If the PERCENT/TIME bit is zero, format progress shall be reported in total time elapsed. If the 
PERCENT/TIME bit is set to one, format progress shall be reported in percentage of completion. 

The INCREMENT bit specifies the granularity of progress reported. When set to zero, the device 
reports progress in 5 percent or 5 second increments, depending on the value of the PERCENT/TIME 
bit. When set to one, the device reports progress in 1 percent or 1 second increments, depending on 
the value of the PERCENT/TIME bit. 

NOTE: Initiators should set the INCREMENT bit value to zero to avoid the bus usage penalties 
associated with a value of one. 

Format progress (when requested by setting the PROGRESS bit to one in the CDB) shall be reported 
with a status of CHECK CONDITION (02h), a sense key of NOT READY (02h), and an ASC/ASCQ of 
LOGICAL UNIT NOT READY, FORMAT IN PROGRESS (04h/04h). The SENSE DATA 
INFORMATION field shall contain the total number of increments (percentage complete or time in 
seconds) that have elapsed since command inception. 

Upon successful completion of the FORMAT UNIT command, status shall be set to CHECK 
CONDITION (02h), the sense key to UNIT ATTENTION (06h), and the ASC/ASCQ to EVENT 
STATUS NOTIFICATION/MEDIA CLASS EVENT (38h/04h). The EVENT field contained within the 
SENSE DATA INFORMATION field shall be set to NEW MEDIA READY FOR ACCESS (02h). The 
initiator shall respond by issuing a MODE SENSE command followed by READ CAPACITY command. 
If the FORMAT UNIT command fails, the device shall return a status of CHECK CONDITION (02h), a 
sense key of MEDIA ERROR (03h), an ASC/ASCQ of FORMAT COMMAND FAILED (31 h /01 h). 

After the problem is corrected (e.g., media replaced), and the device becomes ready, the initiator shall 
issue a MODE SENSE command, followed by a READ CAPACITY command to determine the 
device’s physical parameters. 

While a FORMAT UNIT command is in progress, the device shall not process any command received 
but shall respond with the progress report information described above. 
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5.2 READ(10) Command 

The READ(10) command (see Table 4) requests that the device transfer data to the initiator. The most 
recent data value written in the addressed logical block shall be returned. 



The LOGICAL BLOCK ADDRESS field specifies the first logical block of the range of logical blocks 
that shall be read. 

The TRANSFER LENGTH field specifies the number of contiguous logical blocks of data that shall be 
transferred. A transfer length of zero indicates that no logical blocks shall be transferred. This 
condition shall not be considered an error. Any other value indicates the number of logical blocks that 
shall be transferred. 
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5.3 READ CAPACITY command 

The READ CAPACITY command (see Table 5) provides a means for the initiator to request the 
current capacity of the RBC device. 


Table 5 - READ CAPACITY Command Descriptor Block 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

OPERATION CODE (25h) 

1 

Reserved 

2 

Reserved 

3 

Reserved 

4 

Reserved 

5 

Reserved 

6 

Reserved 

7 

Reserved 

8 

Reserved 

9 

CONTROL = OOh 


READ CAPACITY data (see Table 5) shall be returned to the initiator prior to sending GOOD status for 
the command. 



The BLOCK LENGTH in bytes and the RETURNED logical block address are those of the last logical 
block of the media contained in the device. 

If the device does not contain media, then it shall return status of CHECK CONDITION (02h), sense 
key of NOT READY (02h), and an ASC of LOGICAL UNIT NOT READY (04h). The ASCQ shall reflect 
the current state of the device/media. 
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5.4 START STOP UNIT command 

The START STOP UNIT command (see Table 7) requests that the device enable or disable the 
Logical Unit for media access operations and controls certain power conditions. 


Table 7 - START STOP UNIT Command Descriptor Block 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

OPERATION CODE (1 Bh) 

1 

Reserved | immed 

2 

Reserved 

3 

Reserved 

4 

power conditions | Reserved | loej | start 

5 

CONTROL = OOh 


An immediate (immed) bit of zero indicates that status shall be returned after the operation is 
completed. An immed bit of one indicates that status shall be returned as soon as the command 
descriptor block has been validated. 

The other fields in the START STOP UNIT command are described in the following sub-clauses 

5.4.1 Power conditions 

The POWER CONDITIONS field requests that the logical unit be placed into the power condition 
defined in Table 8. If this field contains any valid value other than zero, then the start and the loej 
bits shall be ignored. 

The POWER CONDITIONS field states are shown in Table 8. RBC device support for each state is 
also shown. 
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Table 8 - POWER CONDITIONS 


Code 

Support 

Description 

0 

M 

No change in power condition. 

1 

M 

Place device in Active condition 

2 

M 

Place device in Idle condition 

3 

M 

Place device in Standby condition 

4 


Reserved 

5 

M 

Place device in Sleep condition 

6 


Reserved 

7 

0 

Device Control 

8h - Fh 


Reserved 

Key: M = Command implementation is mandatory 

0 = Command implementation is optional 


Active (condition 1): Devices in the Active state are at their highest power consumption level. 

For hard disk drives, this typically means that the drive is spinning and capable of executing a media 
access command without a significant delay . 

Idle (condition 2): Devices in the Idle state are at a lower power consumption level than when in the 
Active condition, but still have a significant portion of their circuitry consuming power. For hard disk 
drives, this typically means that the drive is spinning, but not capable of performing a media access 
command without a delay. 

Standby (condition 3): Devices in the Standby state are at a lower power consumption level than 
when in the Idle condition and do not have a significant portion of their circuitry consuming power. For 
hard disk drives, this typically means that the drive is not spinning, but the interface is fully active. Prior 
to entering the Standby state the device shall ensure that logical blocks in cache have their most 
recent data value recorded on the physical medium. 

Sleep (condition 5): Devices in the Sleep state are at a lower power consumption level than when in 
the Standby condition and have very little of the drive circuitry consuming power. A device reset may 
be required before access to the device is allowed. Prior to entering the Sleep state the device shall 
ensure that logical blocks in cache have their most recent data value recorded on the physical 
medium. 

Device Control (condition 7): Devices in the Device Control state are allowed to control their own 
power consumption level. However, the level of Device Control is governed by the value of the 
POWER/PERFORMANCE field in RBC device parameter page (see sub-clause Error! Reference 
source not found.). 

The device shall terminate any command received that requires more power consumption than 
allowed by the START STOP UNIT command’s most recent power condition setting. Status shall be 
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set to CHECK CONDITION (02h), the sense key to ILLEGAL REQUEST (05h), and the ASC/ASCQ to 
LOW POWER CONDITION ACTIVE (5Eh/00h). 

It is not an error to request a device be placed into the same power consumption level in which it 
currently resides. 

5.4.2 Control bits 

A LOAD/EJECT (LOEJ) bit of zero requests that no action be taken regarding loading or ejecting the 
medium. A LOEJ bit of one requests that the medium shall be ejected if the START bit is zero. A LOEJ 
bit, when set to one, requests that the medium is to be loaded if the START bit is one. 

A START bit of zero requests that the device be stopped (media is inaccessible for data transfers). A 
START bit of one requests the device be made ready for use. Table 9 describes the functional 
relationship of the START STOP UNIT control bits. 


Table 9 - START STOP control bit definitions 


Power 

Conditions 

Load/Eject 

START 

Description 

1 -7 

X 

X 

loej and start ignored 

0 

0 

0 

Stop the medium 

0 

0 

1 

Make medium ready 

0 

1 

0 

Unload medium 

0 

1 

1 

Load medium 


5.5 SYNCHRONIZE CACHE command 

The SYNCHRONIZE CACHE command (see Error! Reference source not found.) ensures that 
logical blocks in cache have their most recent data value recorded on the physical medium. If a more 
recent data value for a logical block exists in the cache memory than on the physical medium, then the 
logical block from the cache memory shall be written to the physical medium. Logical blocks are not 
necessarily removed from the cache memory as a result of the SYNCHRONIZE CACHE operation. 
Devices that report the wcd bit set to one in the MODE SENSE RBC Device Parameters page may 
return status of CHECK CONDITION (02h), a sense key of ILLEGAL REQUEST (05h) and an ASC of 
INVALID COMMAND OPERATION CODE (20h). 
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Table 10 - SYNCHRONIZE CACHE Command Descriptor Block 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

OPERATION CODE (35h) 

1 

Reserved 

2 

Reserved 

3 

Reserved 

4 

Reserved 

5 

Reserved 

6 

Reserved 

7 

Reserved 

8 

Reserved 

9 

CONTROL = 00h 


5.6 WRITE(IO) command 

TheWRITE(IO) command (see Table 11) requests that the device write data transferred from the 
initiator to the medium. 



A FORCE UNIT ACCESS (FUA) bit of zero indicates that the device may satisfy the command by 
accessing the cache memory if the WCD bit inRBC mode page 06h (see 5.8.3.) is set to zero. For 
write operations, logical blocks may be transferred directly to the cache memory. GOOD status may 
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be returned to the initiator prior to writing the logical blocks to the medium. Any error that occurs after 
GOOD status is returned is a deferred error. 

A fua bit of one indicates that the device shall access the media in performing the command prior to 
returning GOOD status. A WRITE command shall not return GOOD status until the logical blocks have 
actually been written on the media (i.e. the data is not write cached). 

If the device supports write caching, FUA support shall be implemented. If write caching is NOT 
supported then the FUA bit may be ignored. 

The LOGICAL BLOCK ADDRESS field specifies the first logical block of the range of logical blocks 
that shall be written. 

The TRANSFER LENGTH field specifies the number of contiguous logical blocks of data that shall be 
transferred. A TRANSFER LENGTH of zero indicates that no logical blocks shall be transferred. This 
condition shall not be considered an error. Any other value indicates the number of logical blocks that 
shall be transferred. 


5.7 VERIFY command 

The VERIFY command (see Table 12) requests that the device verify the data written on the medium. 



The logical block address field specifies the starting logical block address on the device for the data 
to be accessed. 

The verification length field specifies the number of contiguous logical blocks of data that shall be 
verified. A verification length of zero indicates that no logical blocks shall be verified. This 
condition shall not be considered an error. Any other value indicates the number of logical blocks that 
shall be verified. 

The VERIFY command verifies that the data written on the media by a previous WRITE command is 
readable without any uncorrectable errors at the time of execution of the command. It does not 
guarantee the information is complete or valid 

5.8 MODE parameters 

This clause describes the header and page used with the MODE SELECT and MODE SENSE 
commands that are applicable to RBC devices. 
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5.8.1 Mode parameter list 

The mode parameter list shown in Table 12 contains a header followed by the RBC Device 
Parameters page. No block descriptor is required for RBC devices. 


Table 13 - Mode parameter list 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0-3 

Mode parameter header 

4-17 

RBC device parameter page 


5.8.2. Mode Parameter header 


The mode parameter header is described in SPC-2. For RBCdevices the MEDIUM TYPE, DEVICE¬ 
SPECIFIC PARAMETER and BLOCK DESCRIPTOR LENGTH fields shall contain zero. 

5.8.3. RBC device parameter page 

The RBC Device Parameters page (see Table 14) is intended to provide general configuration 
information and to allow modification of that configuration, when permitted by the device. An initiator 
may attempt to change any or all parameters contained in the page. No error status shall be returned 
for parameters that are not changeable. 

The initiator may issue a MODE SENSE command for the same page in order to determine which 
parameters have changed. 


Table 14 - RBC Device Parameters page format 


Bit 

Byte 

7 

6 

5 4 3 2 1 0 

0 

PS = 1 

rsvd 

PAGE CODE (06h) 

1 

PAGE LENGTH (OBh) 

2 

Reserved | wcd 

3 

(MSB) 



4 


LOGICAL BLOCK SIZE 

(LSB) 

5 

(MSB) 



6 



7 


NUMBER OF LOGICAL BLOCKS 

8 



9 


(LSB) 

10 

POWER/PERFORMANCE 

11 

Reserved | readd | writed | formatd | lockd 

12 

Reserved 


A WRITE CACHE DISABLE (WCD) bit of zero specifies that the device may return GOOD status for a 
WRITE command after successfully receiving the data and prior to having successfully written it to the 
medium. A WCD bit of one specifies that the device shall return GOOD status for a WRITE command 
after successfully writing all of the data to the medium. 

Devices that cannot physically lock the media or are unable to prevent media removal (e.g., floppy 
drives, PCMCIA drives, Flash cards, etc.) shall ignore the WCD bit and shall report WCD equal to 1 in 
Mode Sense information. 
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The LOGICAL BLOCK SIZE field indicates the number of user data bytes contained in a logical block. 
The NUMBER OF LOGICAL BLOCKS field indicates the number of logical blocks contained in the 
user data area. 

Setting the POWER CONDITIONS field of the START STOP UNIT command to Device Control (07h) 
enables the POWER/PERFORMANCE field. 

The POWER/PERFORMANCE field specifies the POWER/PERFORMANCE management level. 
Higher values permit the device to give more emphasis to performance than power conservation. A 
value of FFh causes the drive to provide the highest performance possible, not affected by power 
conservation. A value of OOh causes the drive to provide the highest power conservation, regardless of 
its effect on performance. 

Changes in the level of power and performance for specific values of the POWER/PERFORMANCE 
field are vendor specific 

A READ DISABLED (READD) bit of zero indicates that the media may be read by an initiator. A 
READD bit of one indicates that an initiator cannot read the media. 

A WRITE DISABLED (WRITED) bit of zero indicates that the media may be written. A WRITED bit of 
one indicates that an initiator cannot write the media. 

A format disabled (formatd) bit of zero indicates that the media may be formatted. A formatd bit of 
one indicates that an initiator cannot format the media. The formatd bit shall not be set to zero if the 
writed bit is set to one. 

A lock disabled (LOCKD) bit of zero indicates that the media may be locked by the 
PREVENT/ALLOW MEDIUM REMOVAL command. A LOCKD bit, when set to one, indicates that the 
media cannot be locked by the PREVENT/ALLOW MEDIUM REMOVAL command. If the RMB bit in 
the standard INQUIRY command data is not set to one, then the LOCKD bit shall be set to one. 

6 SPC-2 Implementation Requirements For RBC Devices 

RBC devices require several commands defined in SPC-2 to function in a system. Bit and field 
exceptions contained in those commands listed in Table 15 are described in the following clauses. 


Table 15 - Required SPC-2 commands 


Command name 

Opcode 

Command Support 

Reference 



Fixed 

Removable 


INQUIRY 

12h 

M 

M 

SPC-2 

MODE SELECT(6) 

15h 

M 

M 

SPC-2 

MODE SENSE(6) 

1 Ah 

M 

M 

SPC-2 

PREVENT/ALLOW MEDIUM REMOVAL 

1 Eh 

N/A 

M 

SPC-2 

REQUEST SENSE 

03h 

0 

0 

SPC-2 

TEST UNIT READY 

OOh 

M 

M 

SPC-2 

WRITE BUFFER 

3Bh 

M 

0 

SPC-2 

Command Support key: M = support is mandatory; N/A = not applicable; 0 = support is optional. || 


6.1 INQUIRY command 

The standard INQUIRY data format is reproduced in Table 16. Several INQUIRY data bits and fields 
are restricted for RBC compatibility. Only the restricted fields and their values are shown. Refer to 
SPC-2 for descriptions of fields and bits not shown. 
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Table 16 - Standard Inquiry data format 


Bit 

Byte 

7 

6 

5 

4 

3 

2 

1 

0 

0 


PERIPHERAL DEVICE TYPE = 0E h || 

1 

RMB | J| 

2 



3 

AERC | 

NACA=0 | i 

4 

1 

5 


1 

6 









7 

RELADR=0 




LINKED=0 




8 









9 


















n 



RBC devices are identified by a PERIPHERAL DEVICE TYPE field set to 0E h. 

A REMOVABLE MEDIUM BIT (RMB) of zero indicates that the medium is not removable. A rmb bit of 
one indicates that the medium is removable. 

If the transport protocol provides a mechanism for asynchronous event reporting, RBC devices shall 
support the function and indicate that support by setting the ASYNCHRONOUS EVENT REPORTING 
CAPABILITY (AERC) bit to one. 

RBC devices shall report sense data using the AUTOSENSE method if the transport protocol supports 
this function. RBC devices shall clear all tasks as the result of any device error. 

RBC devices shall not support Auto Contingent Allegiance and ignore the Normal ACA bit in the CDB 
Control byte. Therefore, RBC devices shall return a zero in the Normal ACA bit in Inquiry data (shown 
as NACA in table 15). 

The RELADR bit shall be set to zero. Relative Addressing is not supported by RBC devices. 

The LINKED bit shall be set to zero. LINKED commands are not supported by RBC devices. 

Support of other bits and fields in the INQUIRY command is not defined be this standard. For 
additional requirements, refer to SPC-2. 

6.1.1 INQUIRY vital product data pages 

This clause describes the vital product data pages that are mandatory for RBC devices. This standard 
defines the required pages but not the page content. 

6.1.1.1 Unit serial number page 

The Unit Serial Number page, 80h, shall be supported by RBC devices. 

6.1.1.2 Device Identification page 

The Vital Product Data Device Identification page, 83h, shall be supported by RBC devices. 
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6.2 MODE SELECT(6) command 

The MODE SELECT(6) command (see Table 17) provides a means for an initiator to specify device 
parameters to a RBC device. RBC devices shall also implement the MODE SENSE(6) command. 


Table 17 - MODE SELECT(6) Command Descriptor Block 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

OPERATION CODE (15h) 

1 

| PF = 1 | SP 

2 

Reserved 

3 

Reserved 

4 

PARAMETER LIST LENGTH 

4 

Reserved 

5 

CONTROL = 00h 


The page format (PF) bit shall be set to one. 

An initiator may attempt to change any or all parameters contained in a mode page The device shall 
ignore non-changeable parameters in the MODE SELECT parameter data. This shall not be 
considered an error. 

The initiator may issue a MODE SENSE command for the same page in order to determine which 
parameters have changed. 

6.2.1 SAVE PAGES (SP) bit support 

For non-removable medium devices the SAVE PAGES (SP) bit shall be set to one. This indicates that 
the device shall perform the specified MODE SELECT operation and shall save, to a non-volatile 
vendor-specific location, all the changeable pages, including any sent with the command. 

For removable medium devices support of the SP bit is optional. Such devices may be unable to save 
changeable information to a non-volatile medium. Therefore, if the SP bit is set to one, removable 
medium devices may return a status of CHECK CONDITION (02h), a sense key of ILLEGAL 
REQUEST (05h) and an ASC of INVALID FIELD IN CDB (24h). 


20 







BSR NCITS 330 


6.3 MODE SENSE(6) command 

The MODE SENSE(6) command (see Table 18) provides a means for an RBC device to report device 
parameters to an initiator. It is a complementary command to the MODE SELECT(6) command. 


Table 18 - MODE SENSE(6) Command Descriptor Block 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

OPERATION CODE (1 Ah) 

1 

| DBD = 1 | 

2 

PC | PAGE CODE 

3 

Reserved 

4 

ALLOCATION LENGTH 

5 

CONTROL = 00h 


The DISABLE BLOCK DESCRIPTORS (DBD) bit shall be set to one. 

The PAGE CONTROL (PC) field defines the type of mode parameter values to be returned in the 
mode page. 

The device shall respond to PC values in the following manner: 

a) If Current values are requested, report the Current values of the mode parameters established by 
the last MODE SELECT command. If the device implements no distinction between current and 
saved parameters, then it shall report identical values in response to a PC of either 00b or 11 b. If 
Saved or Current values are not available, report Default values. 

b) If Default values are requested, report the Default values; 

c) If Saved values are requested, report valid restored mode parameters, or restore the mode 
parameters and report them. 

6.4 PREVENT ALLOW MEDIUM REMOVAL 

RBC devices shall support the PREVENT ALLOW MEDIUM REMOVAL command if the REMOVABLE 
MEDIUM BIT (RMB) bit is set to one in the INQUIRY command standard data. 

6.5 REQUEST SENSE command 

RBC devices shall support the REQUEST SENSE command if AUTOSENSE Data is not provided or if 
either Asynchronous Event Notification or the GET EVENT STATUS NOTIFICATION command is not 
supported. 

If the REQUEST SENSE command is supported it shall be implemented as described in the SPC-2 
specification. 

6.6 TEST UNIT READY command 

RBC devices shall report information exceptions via the unit attention condition (with the associated 
asynchronous event notification, if enabled) or the TEST UNIT READY response. The TEST UNIT 
READY status response shall include information exception status only after a threshold has been 
exceeded. Once the associated asynchronous event notification has been successfully sent to the 
initiator the device shall clear the information exception status from the TEST UNIT READY response. 
The required Sense Key is RECOVERED ERROR (01 h), and the ASC is FAILURE PREDICTION 
THRESHOLD EXCEEDED (5Dh). The ASCQ values are described in Table 19. 
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Table 19 - FAILURE PREDICTION ASCQ XY definitions 


ASCQ X 

Description 

ASCQ Y 

Description 

Oh 

Defined by SPC-2 

Oh 

General hard drive failure 

1h 

Hardware impending failure 

1h 

Drive error threshold exceeding 
limits 

2h 

Controller impending failure 

2h 

Data error rate exceeding limits 

3h 

Data Channel impending failure 

3h 

Seek error rate exceeding limits 

4h 

Servo impending failure 

4h 

LBA reassignment exceeding limits 

5h 

Spindle impending failure 

5h 

Access times exceeding limits 

6h 

Firmware impending failure 

6h 

Start Unit times exceeding limits 

7h 

Reserved 

7h 

Channel parametrics indicate 
impending failure 

8h 

Vendor Specific in SPC-2 

8h 

Controller detected impending 
failure 

9h 

Vendor Specific in SPC-2 

9h 

Throughput performance 

Ah 

Vendor Specific in SPC-2 

Ah 

Seek time performance 

Bh 

Vendor Specific in SPC-2 

Bh 

Spin-up retry count 

Ch 

Vendor Specific in SPC-2 

Ch 

Drive calibration retry count 

Dh 

Vendor Specific in SPC-2 

Dh 

Reserved 

Eh 

Vendor Specific in SPC-2 

Eh 

Reserved 

Fh 

Refer to SPC-2 

Fh 

Reserved 


6.7 WRITE BUFFER Command 

The WRITE BUFFER command (see Table 20) is used to download and save microcode. RBC 
devices are required to support Modes 101 b and 111b. Support for all other modes is optional. 
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6.7.1 Download Microcode and save mode (101b) 

In this mode, vendor-specific Microcode or control information shall be transferred to the device and, if 
the WRITE BUFFER command is completed successfully, shall also be saved in a non-volatile 
memory space (semiconductor, disk, or other). The downloaded code shall then be effective after 
each power-cycle and reset until it is supplanted in another download Microcode and save operation. 
When the WRITE BUFFER command has completed successfully, the device shall generate a unit 
attention condition. If asynchronous event notification is enabled, all initiators except the one that 
issued the WRITE BUFFER command shall be notified of the unit attention condition. The device shall 
set the sense key to UNIT ATTENTION (02h) and the ASC/ASCQ to MICROCODE HAS BEEN 
CHANGED (3Fh / 01 h). 

The PARAMETER LIST LENGTH specifies the maximum number of bytes that shall be transferred 
from the initiator to the device. 

If the logical unit cannot accept this command because of a device condition, the device shall 
terminate the command and return a status of CHECK CONDITION (02h), a sense key of ILLEGAL 
REQUEST (05h) and an ASC of COMMAND SEQUENCE ERROR (2Ch). 

6.7.2 Download Microcode with offsets and save mode (111b) 

In this mode, the initiator may split the transfer of the vendor-specific microcode or control information 
over two or more WRITE BUFFER commands. If the logical unit cannot accept this command because 
of a device condition, the device shall terminate the command and return a status of CHECK 
CONDITION (02h), a sense key of ILLEGAL REQUEST (05h) and an ASC of COMMAND 
SEQUENCE ERROR (2Ch). 

Refer to SPC-2 for a complete description of this mode. 

7 Asynchronous Event Notification for RBC devices 

RBC devices shall notify initiators of the ability to support asynchronous event notification by setting 
the ASYNCHRONOUS EVENT REPORTING CAPABILITY (AERC) bit to one in the standard data 
format of the INQUIRY command (see SPC-2). 

Table 21 describes conditions that may be communicated to an initiator as an asynchronous event. 
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Table 21 - Asynchronous Event conditions 


Sense 

key 

ASC 

Description 

01 h 

5Dh 

RECOVERED ERROR. FAILURE PREDICTION 

THRESHOLD EXCEEDED. 

02h 

04h 

LOGICAL UNIT NOT READY (reported only on transition or 
at power on). 

03h 

nnh 

MEDIUM ERROR. Multiple causes. 

06h 

38h 

Unit Attention. Event Status Notification. 

06h 

5Eh 

Unit Attention. Power condition Change Notification. 

06h 

28h 

Unit Attention. Not Ready to Ready transition. Medium may 
have changed. 

06h 

29h 

Unit Attention. Power on reset, bus reset, etc. 

- This list is for illustration purposes. It is not intended to be a complete list. 


7.1 Unit Attention 

A unit attention condition may be reported via asynchronous event notification. Logical units may 
queue unit attention conditions; more than one unit attention condition may exist at the same time. 
Refer to Table 21 for a description of unit attention conditions that may be reported via asynchronous 
event notification. 

7.1.1 Power condition change notification 

RBC devices shall notify an initiator of the intent to change power conditions via asynchronous event 
notification. The status value shall be set to CHECK CONDITION (02h), the sense key to UNIT 
ATTENTION (06h), and the ASC to POWER CONDITION CHANGE NOTIFICATION (5Eh). The 
ASCQ shall be set to the value of the new power condition plus 40h as shown in Table 22. 

Table 22 - Power condition sense code and qualifier values 
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ASC 

ASCQ 

Description 

5E h 

41 h 

POWER CONDITION CHANGE TO ACTIVE 

5E h 

42 h 

POWER CONDITION CHANGE TO IDLE 

5E h 

43 h 

POWER CONDITION CHANGE TO STANDBY 

5E h 

45h 

POWER CONDITION CHANGE TO SLEEP 

5E h 

47h 

POWER CONDITION CHANGE TO DEVICE 

CONTROL 


An initiator shall respond with a START STOP UNIT command within 8 seconds, if it intends to 
manage the power transition. If the initiator does not respond within 8 seconds, the device may 
transition to a new power condition. If the initiator responds with a START STOP UNIT command 
within 8 seconds, and sets the power condition value equal-to or greater-than the current value, the 
device shall not transition to a lower power condition. 

7.2 Deferred errors 

Deferred errors shall also be reported via asynchronous event notification. Deferred errors may be 
produced as a result of cached data management or support of the Immediate function in commands 
such as START STOP UNIT or FORMAT. 

7.3 Information exception condition notification 

RBC devices shall notify the initiator when an information exception condition exists via asynchronous 
event notification. The status field shall be set to CHECK CONDITION (02h), the sense key to 
RECOVERED ERROR (01 h), the ASC to FAILURE PREDICTION THRESHOLD EXCEEDED (5Dh), 
and the ASCQ to the failure prediction threshold descriptor value. Refer to Table 19 for failure 
prediction ASCQ values. 

7.4 Event status notification 

Through the use of asynchronous event notification, RBC devices may report asynchronous events 
the moment that they occur. 

If the initiator does not support asynchronous event notification, alternative methods shall be used to 
determine the state of the device/media combination. Refer to the GET EVENT STATUS 
NOTIFICATION command for a description of those alternative methods. 

7.4.1 Event Status sense information 

The following sense data shall be used for the event status notification, unit attention condition. The 
status value shall be set to CHECK CONDITION (02h). The sense key shall be set to UNIT 
ATTENTION (06h). The ASC shall be set to EVENT STATUS NOTIFICATION (38h). The ASCQ shall 
be set to the appropriate value shown in Table 23. 
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Table 23 - Event status ASCQ values 


ASCQ 

Name 

Description 

02h 

POWER 
MANAGEMENT 
CLASS EVENT 

Indicates that a Power Management Class event has 
occurred or is impending. 

04h 

MEDIA CLASS 
EVENT 

Indicates that a Media Class event has occurred. 

06h 

DEVICE BUSY 
CLASS EVENT 

Indicates that a Device Busy Class event has 
occurred. 


For each of the sense key, ASC, and ASCQ values above, the contents of the sense data 
information field further describe the event status. The general format of the sense data information 
field is shown in Table 24. 


Table 24 - Event Status information field format 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

EVENT 

1 

STATUS 

2 

EVENT SPECIFIC 

3 

EVENT SPECIFIC 


The following clauses provide specific sense data information field definitions for each ASCQ value 
described in Table 23. 

7.4.2 POWER MANAGEMENT CLASS information field 

Table 25 displays the information field format for POWER MANAGEMENT CLASS EVENTS. 


Table 25 - POWER MANAGEMENT CLASS information field format 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

EVENT 

1 

STATUS 

2 

reserved 

3 

reserved 


Table 26 describes the event field values associated with POWER MANAGEMENT CLASS EVENTS. 
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Table 26 - POWER MANAGEMENT CLASS event field 


event field 

Description 

OOh 

No power condition change. 

01 h 

The device successfully changed to the specified power condition. 

02h 

The device failed to enter the last commanded power condition and is still 
operating at the state specified in the Power Status field. 

03h - FFh 

Reserved. 


Table 27 describes the status field values for POWER MANAGEMENT CLASS events. The state 
names and values match those specified in the START STOP UNIT command, power conditions 
field. 

Table 27 - POWER MANAGEMENT CLASS status field 


STATUS 

field 

Description 

OOh 

Reserved. 

01 h 

The device is in the Active state. 

02h 

The device is in the Idle state. 

03h 

The device is in the Standby state. 

04h 

Reserved. 

05h 

Not Applicable (Sleep state). 

06h 

Reserved. 

07h 

The device is in the Device Control state. 

08h - FFh 

Reserved. 


7.4.3 MEDIA CLASS EVENT INFORMATION field 

Table 28 displays the INFORMATION field format for MEDIA CLASS events. 
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Table 28 - MEDIA CLASS information field format 


Bit 

Byte 

7 6 5 4 3 2 

1 

0 

0 

EVENT 

1 

reserved 

MEDIA 

PRESENT 

DOOR OR 

TRAY 

OPEN 

2 

START SLOT 

3 

END SLOT 


Table 29 describes the event field values associated with MEDIA CLASS events. 

Table 29- MEDIA CLASS event field 


EVENT field 

Description 

OOh 

Media status is unchanged. 

01 h 

Eject request. The user has issued a request to eject the slot or media. 

02h 

The specified slot has received new media and the media is ready to be 
accessed. 

03h 

Media Removal. The media has been removed from the specified slot 
and the device is unable to access the media without user intervention. 

04h - FFh 

Reserved. 


The DOOR OR TRAY OPEN bit indicates the mechanical position of the device’s door or tray. A 
DOOR OR TRAY OPEN value of one indicates that the door or tray is open. A value of zero indicates 
that the door or tray is closed. 

The MEDIA PRESENT bit indicates whether media is installed in the device. A value of one indicates 
that media is present in the device. A value of zero indicates that no media is present. The MEDIA 
PRESENT bit is reported independently from the DOOR OR TRAY OPEN bit. If the device cannot 
report the media state while the door or tray is open, this bit shall be set to zero when the DOOR OR 
TRAY OPEN bit is zero. 

The START SLOT field defines the first slot of a multiple slot device that the media status notification 
applies to. For devices that do not support multiple slots, this field shall be reserved. 

The END SLOT field defines the last slot of a multiple slot device that the media status notification 
applies to. For devices that do not support multiple slots, this field shall be reserved. 

7.4.4 DEVICE BUSY CLASS Event Information Values 

Table 30 displays the INFORMATION field format for DEVICE BUSY CLASS events. 
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Table 30 - DEVICE BUSY CLASS information field format 


Bit 

Byte 

7 6 5 4 3 2 1 0 

0 

EVENT 

1 

STATUS 

2 


3 



Table 31 describes the event field values associated with DEVICE BUSY CLASS events. 


Table 31 - DEVICE BUSY CLASS event field 


EVENT field 

Description 

OOh 

No event is available. 

01 h 

A time-out has occurred. 

02h 

Immediate command progress indication 

02h - FFh 

Reserved. 


Table 32 describes the status field values for DEVICE BUSY CLASS events. 


Table 32 - DEVICE BUSY CLASS status field 


Status field 

Description 

OOh 

No event. The device is ready to accept commands. 

01 h 

The device is in the process of waking up from a lower power condition. 

02h 

The device is in the process of completing an earlier command. 

03h 

The device is in the process of completing a deferred operation, such as 
a write. 

04h - FFh 

Reserved. 


For DEVICE BUSY class events with an event field value of 02h the time field is the percent 
completion of an immediate command. For event field values other than 02h, the time field is the 
predicted amount of time remaining for the device to become not busy, in units of 100 ms. 

7.4.5 Event status retention 

A unit attention condition, generated by an asynchronous event, shall be retained by a device if a bus 
reset takes place after the event has occurred but prior to the unit attention information transfer to the 
initiator. Once the unit attention condition is successfully communicated to the initiator, the device shall 
discard the retained event status information. 

7.4.6 Removable Medium Device Initial Response 
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The following sequence shall occur at power on of removable devices: 

- When ready, the device shall generate an event status notification. The device shall set the 
status value to CHECK CONDITION (02h), the sense key to UNIT ATTENTION (06h), and the 
ASC/ASCQ to EVENT STATUS NOTIFICATION / MEDIA CLASS EVENT (38h/04h). The event 
field shall be set to NEW MEDIA READY FOR ACCESS (02h). 

- The initiator shall issue a MODE SENSE command followed by a READ CAPACITY command. 

- The initiator may issue a START STOP UNIT command with power conditions field values of 1, 
2 or 3. If this command is not issued, the device shall assume the Standby state (power 
conditions = 3). 

- If a START STOP UNIT command is issued, the device shall return event status notification. The 
status value shall be set to CHECK CONDITION (02h), the sense key to UNIT ATTENTION 
(06h), and the ASC/ASCQ to EVENT STATUS NOTIFICATION/POWER MANAGEMENT CLASS 
EVENT (38h/02h). The event field of the information data shall be set to DEVICE 
SUCCESSFULLY CHANGED POWER CONDITIONS (01 h). 
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Annex A (normative) RBC device implementation requirements for SBP-2 


A.1 SBP-2 Definitions 

command block: Space reserved within an ORB to describe a command intended for a logical unit 
that controls device functions or the transfer of data to or from device medium. 

logical unit: The part of the unit architecture that is an instance of a device model, e.g., mass storage, 
CD-ROM or printer. In devices that implement one or more logical units, the device type of 
the logical units may differ. 

login: The process by which an initiator obtains access to a set of device fetch agents. The device 
fetch agents and their control and status registers provide a mechanism for an initiator to 
signal ORB’s to the device. 

quadlet: Four bytes, or 32 bits, of data. 

register: A term used to describe quadlet aligned addresses that may be read or written by Serial Bus 
transactions. In the context of this standard, the use of the term register does not imply a 
specific hardware implementation. For example, the behavior of registers may be 
emulated by a processor. 

sense code: A field in the SBP-2 status block (see clause A.6). Equivalent to the additional sense 
code field in the REQUEST SENSE command sense data. 

sense code qualifier: A field in the SBP-2 status block (see clause A.6). Equivalent to the additional 
sense code field in the REQUEST SENSE command sense data. 

sense key: A field in the SBP-2 status block (see clause A.6). Equivalent to the sense key field in the 
REQUEST SENSE command sense data 

status block: A data structure written to system memory by a device when an operation request block 
has been completed. 

system memory: The portions of any node’s memory that are directly addressable by a Serial Bus 

address and which accepts, at a minimum, quadlet read and write access. Computers are 
the most common example of nodes that make system memory addressable from Serial 
Bus, but any node, including those usually thought of as peripheral devices, may have 
system memory. 

transaction: An exchange between a requester and a responder that consists of a request and a 
response subaction. The request subaction transmits a Serial Bus transaction such as 
quadlet read, block write or lock, from the requesting node to the node intended to 
respond. Some Serial Bus commands include data as well as transaction codes. The 
response subaction returns completion status and sometimes data from the responding 
node to the requesting node. 

unit: A component of a Serial Bus node that provides processing, memory, I/O or some other 

functionality. Once the node is initialized, the unit provides a CSR interface that is typically 
accessed by device driver software at an initiator. A node may have multiple units, which 
normally operate independently of each other. Within this standard, a unit is equivalent to 
a device. 

unit architecture: The specification of the interface to and the services provided by a unit 
implemented within a Serial Bus node. 

unit attention: A state that a logical unit maintains while it has unsolicited status information to report 
to one or more logged-in initiators. A unit attention condition shall be created as described 
elsewhere in this standard or in the applicable command set- and device-dependent 
documents. 

A.2 Acronyms 

The following are abbreviations that are used in this standard: 

CSR Control and Status Register 
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EUI-64 Extended Unique Identifier, 64-bits (ANSI/IEEE 1394-1995) 

ORB Operation request block (see SBP-2) 

SBP-2 Serial Bus Protocol 2 

A.3 SBP-2 storage model (informative) 

The SBP-2 Storage Model describes general characteristics and functions of RBC devices when 
implemented using SBP-2. It is intended to provide design information and lead to a better 
understanding of RBC device functionality. 

A.3.1 Model configuration 

This configuration is used only as an example of a common implementation. The following 
assumptions are made for this model configuration. 

• The device supports a single logical unit. 

• The device does not support multiple initiators. 

• The device does not support Isochronous data transfers. 



Figure A.1 - Mass storage interface block diagram 


A.3.1.1 Model operation 

The block diagram in Figure A.1 indicates the functional blocks contained in an RBC device that 
supports SBP-2. This section describes the function of those blocks when processing a list of ORBs. 
The ORBs contain READ commands in this example. 

After power-on or bus reset, the COMMAND AGENT and MANAGEMENTAGENT engines are in the 
Reset State. 

The initiator reads the RBC device’s Configuration ROM data in order to determine its 1394 
capabilities, SBP-2 capabilities, EUI-64 value, command set identifiers, software versions, and 
M AN AG EM ENTAG ENT CSR address. 

The initiator performs a Login operation prior to any request to the RBC device. To perform a Login, 
the initiator writes its Login ORB address to the MANAGEMENT AGENT register. The Login ORB 
shall contain either the current or master password for the Login to be successful. The RBC device 
returns the Login response to the bus address specified in the Login ORB. One field of the Login 
response contains the COMMAND AGENT’s CSR base address. 

Prior to initiating command transfers, the initiator builds a list of COMMAND BLOCK ORBs in system 
memory. The list may be as short as one ORB, but this example assumes a list length of more than 
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one. The last ORB in the list contains a NULL NEXTORB pointer that indicates the end of the list to 
the RBC device’s COMMANDAGENT fetch engine. 

To transition the COMMAND AGENT state from Reset to Active the initiator writes the offset of the 
first ORB in the ORB list to the RBC device’s ORB POINTER CSR address. This allows the 
COMMAND AGENT fetch engine to begin fetching ORBs from initiator memory. If the initiator writes 
to the Doorbell CSR, the RBC device shall ignore the Doorbell at this time. 

The RBC device fetches ORBs until its ORB space is full or until an ORB containing a NULL 
NEXT ORB pointer is fetched. Fetched ORBs are routed to the Execution engine. The Execution 
engine may reorder the commands contained in the ORBs for best performance. 

As each READ command is executed the RBC device transfers READ data to the initiator’s memory 
space via block write requests. 

Following the data transfer portion of each command the RBC device writes a Status_Block to the 
initiator’s Status_FIFO address. The Status_FIFO address for Command Block ORBs is contained in 
the Login ORB. The status block contains SBP-2 specific command information, such as the 
ORB_offset of the Command_Block ORB associated with this status, as well as general sense 
information. 

: ORBs contain a NOTIFY bit that is to be set to one if a Status_Block is to be written to initiator 
memory after every ORB is executed or set to zero if a Status_Block is to be written only after 
ORB execution encounters an error. This bit is advisory only. RBC devices shall return a 
Status_Block for all ORBs executed. 

If an ORB containing a Null Next_ORB pointer is fetched the Execution engine completes all fetched 
commands, including the one in the just fetched ORB, before the Command_Agent transitions to the 
Suspended state. 

If additional commands are to be executed, the initiator creates a new list of Command_Block ORBs, 
changes the Next_ORB pointer in the last ORB of the old list from NULL to the offset of the first ORB 
in the new list; then writes to the RBC device’s Doorbell CSR address. This transitions the 
Command_Agent to the Active state. 

The RBC device fetches the new Next_ORB pointer value from the last ORB of the old list and begins 
fetching ORBS from the new list at that offset. 

If the Command_Agent fetch engine has not reached the ORB containing a Null Next_ORB pointer 
(and is still in the Active state), the RBC device ignores any writes to the Doorbell CSR address. 

This sequence may continue until the RBC device is reset, power is removed, or an error occurs. 

A.3.2 Reconnect/Power reset support (normative) 

RBC devices shall support the Reconnect management function following a bus reset, as described in 
SBP-2. However, in the case that a Reconnect request occurs following a power reset, RBC devices 
shall perform as follows: 

a) Following a power reset, any previous login information shall be discarded and the device shall 
transition to the Reset State. 

b) If an initiator sends a Reconnect ORB to the device, the device shall return status with RESP set 
to 0, REQUEST COMPLETE, and SBP_status set to Ah, LOGIN ID NOT RECOGNIZED. 

A.4. Configuration ROM support (normative) 

Although most Configuration ROM entries are generic, several contain information that is specific to 
each device type. Hard disk drive specific Configuration ROM information is defined in this section. 
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A.4.1 Unit Directory - Command_Set_Spec_ID 

The COMMAND_SET_SPEC_ID entry (key - 38h) is an immediate entry that specifies the 
organization responsible for the command set definition for the device. 


A.4.2 Unit Directory - Command_Set 

The COMMAND SET entry (key - 39h) is an immediate entry that, in combination with the 
COMMAND_SET_SPEC_ID entry, specifies the command set implemented by the unit. 


A.4.3 Unit Directory - Logical_Unit_Number 

LOGICALUNITNUMBER entry (key - 14h) is an immediate entry that specifies the device type and 
the logical unit number of a logical unit supported by the drive. The format of this entry is defined in 
SBP-2 and duplicated here with additional field information for hard disk drives. 


device_ty 
pe (O^is) | 


Logical unit_number 

J_I_I W 1 _I_I_L 


The DEVICE TYPE field indicates the peripheral device type implemented by the logical unit. The 
value defined for RBC devices is OEh, 

The LOGICAL UNIT NUMBER field indicates the value of a logical unit supported by the drive. For 
hard disk drives that support one logical unit, the value is OOOOh. 

A.5 Security support (normative) 

RBC Devices shall implement security against unauthorized media access as defined in the security 
annex of SBP-2. 

The master password, referenced in SBP-2, is contained in the INQUIRY command, Vital Product 
Data, page 80h. Following a successful Login operation, the initiator shall request that the device 
perform the INQUIRY command, in order to obtain the device’s serial number. 

A.6 Status block support (normative) 

The status block for RBC devices shall be implemented as described in the following text and figure. 
Refer to SBP-2, Annex B, for a complete description of all bits and fields. 

If no exception status is generated, only the first two quadlets (len =1) shall be written to the initiator’s 
STATUS_FIFO address. 

If exception status is generated, the device shall write, at a minimum, the four quadlets (len = 2) 
shown below. This format is required for unsolicited status as well as command status. 


- - - 1 - sbp_status 

_ ORB-offset_hi 







_ ORE 

_offset_lo 


- 

- stat 


: 

: 

i 

_ sen 

_ sense code 

_ sense qualifier 

^ _ information j 
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A.7 Unsolicited Status support (normative) 

RBC devices that support the SBP-2 transport protocol shall implement the generation of unsolicited 
status. Devices shall notify initiators of unsolicited status support by setting the ASYNCHRONOUS 
EVENT REPORTING CAPABILITY (AERC) bit to one in the standard data format of the INQUIRY 
command (see SPC-2). 

As stated in SBP-2, unsolicited status is enabled when the initiator writes to the 
Unsolicited_Status_Enable CSR. Devices default to unsolicited status disabled and only send 
unsolicited status following a write to the Unsolicited_Status_Enable CSR. The 
Unsolicited_Status_Enable CSR is a handshake mechanism and shall be written after every 
unsolicited status event in order to enable another such event. 

A.7.1 Unit attention condition 

A unit attention condition shall persist for a logged-in initiator until a) unsolicited status, that reports the 
unit attention condition, is successfully written to the initiator’s status FIFO address, or b) the initiator’s 
login becomes invalid or is released. Logical units may queue unit attention conditions; more than one 
unit attention condition may exist at the same time. 

A.7.2 Event Status retention 

RBC devices using SBP-2 shall retain event status for a logged in initiator if a bus reset occurs after 
the event has occurred but prior to the unit attention information being sent to the initiator. If the 
initiator fails to reconnect to the device within the reconnect time-out period (see SBP-2), the retained 
event status information shall be discarded. 

If the initiator successfully reconnects, it shall write to the Unsolicited_Status_Enable register. The 
device shall transfer the retained event status, via unsolicited status. Once the event status is 
successfully transferred to the initiator, the device shall discard the retained event status. 
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